Forgive, Forget, & Fall Out — A Framework for Service Failure & Trust

One of the things that makes a service a service is the potential for failure. It's often something of a high wire act, delivering a service: it requires coordination across parts and people, lining up hundreds of small details to make sure that information and money and decisions flow properly, that providers don't do harm to service recipients or staff, even to make sure that the experience feels right beyond its basic utility. Part of where we see value in services is the potential for failure — we seek services out because they provide us with a safety net for things we couldn't otherwise navigate ourselves. Medical care when you're sick; lawyers when you're buying a house; financial advisors when you're trying to dig out of debt or secure your future. These folks are well-paid service providers because the threat of failure if you try and do things without them in these spaces is real.

Providers need to assume a degree of failure, and design for it. More often than not, teams use humans to patch over the holes and soften the rough edges. Think of a call centre, or an escalation to a manager. Solving a failure is a way to patch up or even rebuild the trust that we all lose when a service provider fails us.

That trust is essential: it's what binds a service user into the service over time, keeps them coming back, enables them to become advocates for the service and recommend it to friends and family, and in a macro sense, trust in service quality and integrity is a core component of democratic thriving. There's both a business and social case for building and maintaining trust.

But are all failures, and by extension impacts to confidence and trust, created equal?

More often than we'd like to admit, most of the key lessons we learned in kindergarten are also useful lenses for effective service design. When little Rhonda accidentally spills guava juice on Ezekiel, and apologizes, we encourage Ezekiel to 'forgive and forget'. It's got alliteration, it's got assonance, it's memorable enough for a four year old, so it's good enough for us.

So here's a way of thinking about service failures, and service trust, through the lens of 'forgive' and 'forget'.

First, let's break down what we mean by those two words, here. After a failure happens, a service user is going to start making conscious and unconscious evaluations of their relationship to the service. These are both emotional and rational evaluations: emotional, in the sense of "wow that brush-off from the branch manager made me so angry!" and rational, in the sense of "can I afford to bank here if they're going to lose a payment every now and again?".

So, 'forget' and 'forgive' become a kind of shorthand for different postures in that post-failure relationship.

Forget means that you're not only willing to forgive the failure, but it also means you're not going to hold onto it. You might shrug it off as a mere 'cost of doing business', 'par for the course' failure, and the next time you enter into that service context it's as if it never happened. These are often flukes, small human failures, and one-off — antisystemic wobbles that are ironed out by the service delivery machine in almost all cases.

Forgive means you're willing to move past the failure and maintain a relationship with the service or service provider, but your default posture towards it is fundamentally changed by the failure, shifting into an evaluative mode versus the harm incurred. Often, these kinds of failures are things that are perceived by service users as 'systemic' within the service — that is, things that happen not by fluke but because of fundamental flaws. Service users might be more skeptical, more careful, perhaps even more demanding going forward. Trust and confidence are eroded, but not to a breaking point.

Together, these ideas create a kind of spectrum for describing the postures that people can take in response to failure.

On the one end of the spectrum, there are service failures that we agree to forgive and forget. These are the lightest impacts, with minimal harms, and minimal risk of 'losing' the service user.

Then, in the middle you have "forgive but not forget" failures. Here, there's real harm to the confidence and trust of the service user, but you haven't lost them yet.

Finally, on the far end of the spectrum, you have failures that we "neither forgive nor forget". Here, trust is broken, and while you may not have 'lost' the service user in a business sense, you've lost them emotionally and relationally. They're with you only out of necessity or until a better option comes along.

Straightforward, right?

What we like about this is it gives us a simple framework for starting to categorize the kinds of failures that a service might encounter or create.

What are the "forget" failures? It might be things like:

• The web service being down for maintenance
• Having to reprint a document for signing because the details weren't quite right the first time
• Having to wait a little longer than you'd like because a service is unusually busy

And what failures are in the 'forgive' category? Here, we might think about:

• A reversible error that costs a service user a small amount of money until it's made right
• A failure to remember all the details of a service user's case until they remind the provider
• A change in policy that wasn't well-communicated in advance of the service user re-engaging a service they've used in the past

What, then, are the kinds of failures that are neither forgettable nor forgivable?

• Costing a service user money through service error and failing to correct the error
• Ignored complaints that have escalated through appropriate channels
• Leaving a service user waiting past their appointment time and then failing to see them before business hours close for the day

Notably, certain factors can shift a forgettable failure into a merely forgivable failure, or a forgivable failure into one that can be neither forgiven nor forgotten.

Quantity transforms quality, in this case. The same silly, low-stakes error repeated ten times starts to shift from something forgettable to something that actively shapes your sense of trust and confidence. A lawyer who futzes key details once, requiring re-signing of a contract, may be forgivable, but if it becomes a pattern, then you get worried.

Similarly, the scale of impact can move a failure along the spectrum. A pricing error that costs $0.30 is forgettable; one that costs $3000, even if reversed, is likely to cause a service user to think twice before coming back.

As you audit the services you work on, it can be helpful to think about known past or possible failures. Where does the service break, and what does it cost, in terms of trust and confidence, when it does?

We've built a quick worksheet that can help start this conversation with your team. Try using it during a team retro or during a planning session for the coming quarter or year. Let us know what you think by shooting us an email at hello@october.systems